Schemas 3.0.3
(Version 3.0.3, updated
2013-01-05
by AA6YQ and G3ZOD)
ADX XML Schemas for Amateur Data Interchange Format (ADIF)
Table of Contents
Description
Checks not Required
Limitations
I. Description
ADIF 3.0.2 introduced ADX as an alternative file
format for representing
ADIF employing XML syntax. The ADX XML Schemas supplement this, describing
ADX using the XML Schema definition
language 1.0
The ADX schemas can be used to determine whether ADX complies with
the ADIF specification. If used, they must be applied externally without being
referenced in the <ADX> root element.
Most aspects of the ADIF specification are validated, subject to
some checks that cannot be performed due to being advisory only and others which
are not possible or impractical to check.
Two schemas are provided.
One is specific to ADX 3.0.3 and provides the most accurate representation because it
disallows deprecated features.
A second, non-version specific schema is also provided for situations where the ADX version is not known in advance.
The version-specific schema adx303.xsd is available
here.
The non-version-specific schema adx303generic.xsd is available
here.
II. Checks not Required
- CONTEST_ID element contents are not validated against the "Contest ID" enumeration because the ADIF
field type is "String" (i.e. the enumeration is only advisory).
-
CNTY and MY_CNTY element contents are not validated against the "Secondary Administrative Subdivision"
enumeration because the enumeration values are controlled by external organizations and so are
subject to change without notice..
III. Limitations
- MY_STATE and STATE element contents are not validated against the "Primary Administrative Subdivision"
enumeration due to the excessively long regular expression required.
-
User-defined field names (contents of the USERDEF element nested in the HEADER element) are not
validated against the pre-defined ADIF field names due to the excessively long regular expression
required.
-
USERDEF elements nested in the HEADER element can optionally have either a RANGE or ENUM attribute
but not both; this is not validated.
-
Values in FIELDNAME attributes belonging to USERDEF elements nested in a RECORD element are not
validated against the USERDEF elements in the HEADER element.
-
USERDEF elements nested in RECORD elements do not have their contents validated against the TYPE,
RANGE or ENUM (if any) attributes of the corresponding USERDEF element nested in the HEADER element.
-
APP element contents are not validated against the TYPE attribute (if any) given.
-
In a record, no field may appear in more than one Data Specifier; this is not validated.